Möchten Sie das Beispiel, den Stil und die Struktur des obigen deutschen Textes wiederholen, aber mit neuem Inhalt? Hier ist ein Beispiel: Der Modulmanager in PrestaShop wirft einen XML-Fehler? Nachfolgend erklären wir, warum dies geschieht und wie wir es effektiv beheben – ohne dass Sie Ihren Shop aktualisieren oder die Datenbank ändern müssen.
Die wichtigsten davon sind:
Der Fehler tritt meist direkt im Admin-Panel auf – im Reiter Module oder nach dem Betreten Modulmanager. Die Mitteilungen können wie folgt aussehen:
PrestaShop sendet HTTP-Anfragen an die PrestaShop Addons API, um aktuelle Modullisten abzurufen. Ein Beispiel-Endpunkt sieht so aus:
Der Shop erwartet eine Antwort im XML-Format. Ein Problem tritt auf, wenn:
Was kann im Bedienfeld ausfallen:
Bevor Sie Änderungen vornehmen, ist es ratsam zu prüfen, was sich derzeit in den Dateien befindet. Durch SSH wir führen durch:
Wenn die Datei leer ist, HTML (z. B. eine 503-Fehlerseite) oder JSON anstelle von XML enthält, ist dies die Ursache des Problems.
Die schnellste Lösung ist, den Inhalt der problematischen Dateien durch minimales, korrektes XML zu ersetzen. Per SSH führen wir durch:
Sie können Dateien auch manuell über FTP hochladen. Der Inhalt jeder Datei sollte wie folgt aussehen:
Um das Herunterladen von XML aus der Addons API dauerhaft zu blockieren, erstellen wir einen Klassen-Override Werkzeuge. Wir erstellen eine Datei:
Betreffend den folgenden Inhalt:
Eigenschaft $ist_addons_up = false verhindert, dass PrestaShop versucht, eine Verbindung zur Addons-API herzustellen – und folglich keine XML-Dateien herunterlädt oder überschreibt.
Nachdem die Override-Datei erstellt wurde, leeren wir den Cache. Für PrestaShop 1.7 / 8.x:
Sie können den Cache auch über das Administrationspanel löschen: Erweitert > Leistung > Cache leeren.
Wenn wir kein Override verwenden möchten, können die XML-Dateien auf schreibgeschützt gesetzt werden. PrestaShop kann sie dann nicht überschreiben:
Es ist erwähnenswert, dass die meisten dieser Funktionen in einer Produktionsumgebung ohnehin nicht täglich genutzt werden:
Empfohlene Schritte:
Kontakt
Was sind XML-Dateien im Verzeichnis config/xml/?
PrestaShop speichert lokal mehrere XML-Dateien, die für die Funktionalität bestimmter Abschnitte verantwortlich sind. Module > Modulmanager im Admin-Panel. Sie werden zyklisch von einer externen API abgerufen PrestaShop Addons und im Verzeichnis gespeichert:config/xml/- must_have_modules_list.xml – Liste der von PrestaShop als „Must-Have” gekennzeichneten Module
- modules_native_addons.xml – Liste der in Addons verfügbaren nativen Module
- Standard_Länder_Module_Liste.xml – empfohlene Module für ein bestimmtes Land
- trusted_modules_list.xml – Liste vertrauenswürdiger, von PrestaShop verifizierter Module
Wie sieht ein XML-Fehler aus und wo tritt er auf?
Der Fehler tritt meist direkt im Admin-Panel auf – im Reiter Module oder nach dem Betreten Modulmanager. Die Mitteilungen können wie folgt aussehen:Fehler gefunden: Start-Tag erwartet, '<' nicht gefunden in der Datei must_have_modules_list.xml
Fehler gefunden: Start-Tag erwartet, '<' nicht gefunden in der Datei modules_native_addons.xml
Fehler gefunden: Start-Tag erwartet, '<' nicht gefunden in der Datei default_country_modules_list.xmlHinweis
Diese Fehler treten in PrestaShop 1.7 sowie in PrestaShop 8.x auf. In älteren Versionen 1.6 funktioniert der Mechanismus ähnlich, auch wenn die Speicherorte einiger Dateien abweichen können.
Woher kommt dieser Fehler?
PrestaShop sendet HTTP-Anfragen an die PrestaShop Addons API, um aktuelle Modullisten abzurufen. Ein Beispiel-Endpunkt sieht so aus:https://api.addons.prestashop.com/?version=1.7.8.x&method=listing&action=must-have- API Addons gibt eine Antwort in einem anderen Format zurück (z. B. JSON oder eine HTML-Fehlerseite)
- Die Verbindung zur API ist durch die Firewall oder die Serverkonfiguration blockiert
- Der Server des Shops hat keinen Zugriff auf externe Ressourcen (kein ausgehender HTTP/HTTPS-Verkehr).
- API Addons ist vorübergehend nicht verfügbar oder gibt ein Timeout zurück
- Die PrestaShop-Version ist zu alt und wird nicht mehr von der API unterstützt
Beeinflusst der Fehler die Funktionsweise des Shops?
Erfolg
Das Frontend des Shops, der Warenkorb, Bestellungen, Zahlungen und alle Kaufprozesse funktionieren normal. Der Fehler betrifft ausschließlich das Backend – speziell den Bereich der Modulverwaltung.
- Liste empfohlener Module
- „Must-have”-Bereich im Modulmanager
- Marktplatz-Add-ons, verfügbar über den Administrator
- Modulvorschläge für das Land
- langsamere Seitenladezeit Module (Timeout bei Verbindungsversuch zur API)
Schritt 1 – Überprüfung des Inhalts von XML-Dateien
Bevor Sie Änderungen vornehmen, ist es ratsam zu prüfen, was sich derzeit in den Dateien befindet. Durch SSH wir führen durch:Katze config/xml/must_have_modules_list.xmlTipp
Um den Inhalt einer Datei zu überprüfen, können Sie auch den Dateimanager im Hosting-Panel (z. B. Hestia CP, cPanel) oder einen FTP-Client verwenden – ein SSH-Zugriff ist nicht erforderlich.
Schritt 2 – Austausch der Dateien gegen korrektes XML
Die schnellste Lösung ist, den Inhalt der problematischen Dateien durch minimales, korrektes XML zu ersetzen. Per SSH führen wir durch:echo '' > config/xml/must_have_modules_list.xml
echo '' > config/xml/modules_native_addons.xml
echo '' > config/xml/default_country_modules_list.xml
echo '' > config/xml/trusted_modules_list.xmlWarnung
Nur der Austausch der Dateien wird das Problem vorübergehend lösen. PrestaShop wird beim nächsten Aktualisieren der Modulseite versuchen, die Daten erneut von der API abzurufen und könnte die Dateien mit einer fehlerhaften Antwort überschreiben.
Schritt 3 – Dauerhafte Lösung durch Klassen-Override
Um das Herunterladen von XML aus der Addons API dauerhaft zu blockieren, erstellen wir einen Klassen-Override Werkzeuge. Wir erstellen eine Datei:override/classes/Tools.php<?php
class Tools extends ToolsCore
{
protected static $is_addons_up = false;
}Nachdem die Override-Datei erstellt wurde, leeren wir den Cache. Für PrestaShop 1.7 / 8.x:
rm -rf var/cache/dev/*
rm -rf var/cache/prod/*Infos
Nach Anwendung von "override" funktioniert der Modulbereich weiterhin vollumfänglich – Module können aus ZIP-Dateien installiert, deinstalliert und aktualisiert werden. Nur die Integration mit dem Addons-Marktplatz im Admin-Panel wird deaktiviert.
Alternative – Schreibschutz für Dateien
Wenn wir kein Override verwenden möchten, können die XML-Dateien auf schreibgeschützt gesetzt werden. PrestaShop kann sie dann nicht überschreiben:chmod 444 config/xml/must_have_modules_list.xml
chmod 444 config/xml/modules_native_addons.xml
chmod 444 config/xml/default_country_modules_list.xml
chmod 444 config/xml/trusted_modules_list.xmlHinweis
Die Methode mit chmod ist einfacher, aber sie eliminiert nicht die Versuche, sich mit der API zu verbinden – PrestaShop wird sie weiterhin ausführen, was das Laden der Modulseiten verlangsamen kann. Das Überschreiben der Klasse Tools ist eine technisch sauberere Lösung.
Was verlieren wir nicht, wenn wir die Add-ons-API deaktivieren?
Es ist erwähnenswert, dass die meisten dieser Funktionen in einer Produktionsumgebung ohnehin nicht täglich genutzt werden:| Funktion | Nachdem die API deaktiviert wurde |
| Frontend des Shops | Funktioniert unverändert |
| Bestellungen und Warenkorb | Funktioniert unverändert |
| Installation von Modulen aus ZIP | Funktioniert unverändert |
| Modulaktualisierungen | Funktioniert unverändert |
| Marktplatz-Add-ons im Admin-Bereich | Nicht verfügbar |
| Empfehlenswerte Module „Must-have” | Nicht verfügbar |
| Modulvorschläge für das Land | Nicht verfügbar |
Wann kann der Fehler erneut auftreten?
Wenn Sie nur Dateiersetzungen ohne Überschreiben oder chmod vornehmen, kann der Fehler nach folgendem Zeitraum zurückkehren:- Aktualisierung der Seite "Modul-Manager"
- PrestaShop Cron-Auftrag starten
- PrestaShop-Aktualisierung
- Cache leeren
Zusammenfassung
XML-Fehler im PrestaShop-Panel ist ein Kommunikationsproblem zwischen einer alten Shop-Version und der Addons-API – es handelt sich nicht um einen Serverausfall, ein Datenbankproblem oder Malware-Befall. Der Shop funktioniert normal. Die Lösung ist schnell und erfordert kein Update von PrestaShop.Empfohlene Schritte:
- Überprüfung des Dateiinhaltes config/xml/
- Ersetzen von Dateien durch minimal gültiges XML
- Hinzufügen der Überschreibung der Klasse Werkzeuge z $ist_addons_up = false
- PrestaShop-Cache leeren
Kontakt
